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FOREWORD 


I  am  pleased  to  Introduce  this  handbook  as  a  proven 
tool  for  developing  improved  preventive  maintenance 
programs  for  Navy  ships. 

Our  goal  to  have  a  fleet  of  reliable  modern  ships 
requires  that  we  be  effective  in  maintaining  their 
readiness.  Effective  preventive  maintenance  is  a  key 
requirement.  As  maintainers  we  must  focus  on  not  one, 
but  two  objectives  —  do  things  right  —  and  do  the 
right  things.  This  handbook  introduces  Reliability- 
Centered  Maintenance  (RCM),  a  process  designed  to  help 
us  achieve  both  of  these  objectives. 

I  hope  you  will  find  this  handbook  both  stimulating 
and  informative  as  you  work  to  develop  and  implement 
RCM-based  preventive  maintenance  programs  in  Navy 
ships. 


S.G.  CATOLA, 

Rear  Admiral,  United  States  Navy 
Principal  Deputy  Commander 
for  Logistics 
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PREFACE 


--''This  handbook  is  a  fourth  edition  of  one  printed  early  in 

1979  for  use  as  a  training  aid.  The  content  has  been  revised 
considerably  to: 

Respond  to  experience  gained  during  the  training  process; 

Directly  support  the  requirements  of  MIL-P-24534A  (Navy)  .. 

The  purpose  of  this  handbook  is  to  introduce  you  to  the 
ideas  about  preventive  maintenance,  program  design  that  are  the 
foundation  for  the  method  called  ^Reliability-Centered  Mainte¬ 
nance  (RCM)**V  Applying  RCM  requires  an  understanding  of  these 
ideas.  Specific  application  also  requires  an  understanding  of 
each  ship  system,  its  failures,  and  the  impact  of  these  failures. 
RCM  does  not  presume  that  hardware  needs  preventive  maintenance 
but  uses  knowledge  about  systems,  their  functions,  and  their 
failures  to  identify  applicable  and  effective  preventive  mainte¬ 
nance  tasks.  _ _ 

This  handbook  is  intended  to  supplement  the  applicable 
Military  Specification(s) ,  not  to  supplant  them. 

RCM  provides  an  opportunity  to  apply  reason  —  not  dogma ^ 
—  to  preventive  maintenance  program  design.  Well  used,  it  will 
provide  significant  benefits.  Where  data  are  limited,  unstruc¬ 
tured  judgement  will  always  be  offered  as  an  alternative  to 
analysis.  Whatever  the  level  of  data  available,  a  structured  de¬ 
cision  logic  such  as  that  described  in  this  handbook  will  provide 
better  decisions.  RCM  is  not  a  cure-all,  but  it  is  a  logical  way 
to  attack  important  preventive  maintenance  task  needs  using  the 
available  information  and  knowledge  that  can  be  brought  to  the 
problem.  Obviously,  judgement  has  a  role  in  this  process.  Just 
be  sure  that  you  use  it  after  collecting  the  facts,  not  Instead 
of  collecting  them. 


*  A  belief  handed  down  by  authority  as  true  and  indisputable. 
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I.  INTRODUCTION  TO  RCM 


A.  HISTORY 

Until  recently,  very  few  of  us  had  given  much  thought  to 
logical  methods  for  designing  preventive  maintenance  programs.  In 
order  to  help  you  get  quickly  up  to  speed,  the  first  part  of  this 
manual  presents  a  brief  review  of  the  work  done  before  this 
handbook  was  prepared. 

There  is,  before  1960,  no  record  of  any  effort  to  look 
deeply  into  the  effectiveness  of  preventive  maintenance  as  a 
process  for  avoiding  failure.  Those  involved  in  preventive 
maintenance  apparently  believed  so  surely  that  what  they  were 
doing  was  correct  that  they  saw  no  need  to  prove  its  truth.  They 
reacted  almost  entirely  to  each  event  as  it  occurred  rather  than 
generalizing  their  experience  by  inductive  reasoning. 

In  the  late  50's,  the  new  presence  of  jet  aircraft  fleets 
and  a  growing  expertise  in  the  process  of  analysis  stimulated 
airline  Interest  in  improving  the  effectiveness  of  preventive 
maintenance  for  transport  aircraft.  Since  the  underlying  reason 
for  preventive  maintenance  is  the  belief  that  the  reliability  of 
hardware  decreases  with  its  use,  the  first  work  examined  the 
relationship  between  reliability  and  age,  using  the  techniques 
already  used  by  actuaries  in  life  insurance  companies. 

To  those  who  believed  that  reliability  always  decreased  with 
age,  the  results  were  disappointing.  In  fact,  there  was  an 
unexpected  discovery  of  the  opposite  —  a  large  number  of 
frequent,  early  failures,  or  "infant  mortality"  that  dominated 
many  units'  life  experiences.  These  had  been  expected  in 
electronic  hardware,  but  not  in  the  wide  range  of  hardware  in 
which  they  appeared.  It  is  safe  to  say  that  infant  mortality 
after  rework  is  likely  in  all  complex  assemblies. 

In  1967,  airlines  first  applied  decision  tree  logic  to  the 
problem  of  identifying  preventive  maintenance  task  needs.  It 
provided  an  efficient  approach,  since  it  directly  faced  the 
primary  question  of  the  impact  of  unreliability  on  operations. 
In  1968,  a  decision  tree  logic  formed  the  basis  for  the  design  of 
the  Initial  maintenance  program  for  the  Boeing  747.  Since  then, 
similar  methods  have  been  used  on  the  DC10,  L-1011,  Concorde, 
A-300,  Boeing  767  and  757. 

In  the  early  70's,  this  work  attracted  the  attention  of  the 
Office  of  the  Secretary  of  Defense,  the  Naval  Air  Systems 
Command,  the  Air  Force,  and  the  Army.  The  Navy  was  the  first  to 
apply  this  new  method  for  preventive  maintenance  program  design, 
now  called  Reliability-Centered  Maintenance  (RCM),  to  both 
newly-designed  and  in-service  aircraft  —  the  S-3,  P-3,  and  the 
F-4.  The  first  work  by  the  Naval  Sea  Systems  Command  to  apply 
this  method  to  ships  began  shortly  thereafter. 
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The  prototype  application  to  surface  ships  was  installed  in 
U.S.S.  ROARK  (FF-1053)  in  1978.  In  mid-1979,  as  the  result  of 
evaluation  of  RCM  on  4  additional  FF-1052  class  ships,  an  ongoing 
program  for  application  of  RCM  to  both  new  and  in-service  naval 
ships  was  directed  by  the  Chief  of  Naval  Operations.  Installa¬ 
tions  have  been  completed,  or  are  in  process,  in  FF-1052,  FFG-7, 
DD-963,  LSD-41,  LCAC,  CG-47,  ARS-50,  MCM-1  and  CVN-71. 


B.  THE  BASIS  FOR  RCM 

RCM  is  derived  from  careful  consideration  of  the  following 
questions.  Some  of  these  were  overlooked  in  previous  methods  for 
selecting  preventive  maintenance  tasks. 

•  What  does  the  hardware  do? 

•  What  functional  failures  occur? 

•  What  are  the  likely  consequences? 

•  What  can  be  done  to  prevent  them? 

A  time-directed  approach  to  preventive  maintenance,  in  which  the 
ultimate  task  is  a  scheduled,  fixed-content  overhaul,  has  been 
dogmatically  applied  to  many  kinds  of  hardware.  For  surface 
ships,  in  particular,  very  little  analysis  of  in-service  experi¬ 
ence  to  validate  the  need  for  scheduled  equipment  overhauls  has 
been  done.  In  fact,  the  absence  of  really  useful  in-service 
reliability  information  about  ship  systems  is  the  factor  that 
constrains  the  potential  benefits  of  RCM  to  ships. 

RCM  is  reliability-centered.  Its  objective  Is  to  maintain 
the  inherent  reliability  of  the  design,  recognizing  that  changes 
in  inherent  reliability  are  the  province  of  design. 

Rather  than  focusing  immediately  on  subsystems  or  equipments 
and  asking  "What  preventive  maintenance  can  be  done?”,  RCM  starts 
from  the  top  by: 

•  Partitioning  the  ships  into  systems  and  subsystems  that 
require  analysis; 

•  Identifying  additional  functionally  significant  items; 

•  Determining  the  maintenance  requirements  (tasks)  for  each 
significant  item  based  on  analysis  of  its  functions,  both 
evident  and  hidden,  and  its  dominant  failure  modes; 

•  Determining  when,  how,  and  by  whom  each  task  will  be 
done; 

•  Identifying  needs  for  design  change  when  safety  is 
threatened  by  a  failure  for  which  there  is  no  applicable 
and  effective  task;  and 

•  Using  information  obtained  from  operations  and  appropri¬ 
ate  analytical  techniques  to  adjust  these  intervals  and 
revise  task  content. 


c. 


The  ENVIRONMENT 


In  the  past,  there  has  been  a  distinct  separation  between 
"organizational  maintenance”  and  other  maintenance  performed  by 
shore  activities.  This  separation  has  applied  to  maintenance 
requirements  planning,  the  processes  for  determining  maintenance 
requirements,  and  the  documentation  of  these  requirements  and  of 
work  done.  Coordination,  if  any,  has  usually  been  incidental. 

Recently,  recognition  of  the  desirability  of  reducing 
organizational  (on-ship)  maintenance  resource  requirements  has 
resulted  in  progress  toward  coordination,  if  not  integration,  of 
planning  for  the  total  preventive  maintenance  requirements  for 
some  ship  classes.  (If  you  are  familiar  with  the  LO-MIX  and 
DDEOC  concepts,  you  will  recognize  this  progress.) 

To  achieve  its  objective  of  applicability  and  effectiveness, 
preventive  maintenance  must  be  a  cohesive  set  of  requirements 
that,  together,  represent  a  harmonious,  orderly  set  of  tasks 
performed  by  the  maintenance  resource  at  large.  Hardware  cannot 
react  to  where  or  by  whom  preventive  maintenance  is  done,  only  to 
what  is  done. 

The  task  of  the  raanager(s)  of  preventive  maintenance 
requirements  is  to  organize  the  processes  for  establishing  and 
maintaining  these  requirements  so  that  for  the  life  of  the 
affected  hardware,  they  have  the  highest  degree  of  applicability 
and  effectiveness. 

At  present,  considerably  more  can  be  done  to  achieve  that 
objective.  A  suggested  ultimate  objective  is  to: 

•  Integrate  the  resnonsibilitv  for  life  cycle  preventive 
maintenance  program  management  for  each  ship  class. 

•  Bring  the  resources  of  the  design  engineer,  in-service 
technician/mechanic  and  maintenance  analyst  together  when 
developing  or  changing  preventive  maintenance  programs. 


D.  SCOPE 

The  application  of  RCM  described  in  Military  Specification 
MIL-P-24534A  (Navy)  is  focused  on  systems.  Although  prior 
methods  for  developing  preventive  maintenance  requirements  have 
dealt  primarily  with  systems  needs  at  the  organizational  level, 
this  specification  is  intended  -o  be  applied  to  the  development 
of  life-cycle  preventive  mai  ze  requirements  for  all 
hardware,  including  structures,  ival  ships. 
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II.  PRINCIPLES  AND  THEORY 
OF  MAINTENANCE 


This  section  of  the  handbook  serves  to  review  some  basic 
ideas  that  underlie  the  performance  of  tasks  to  prevent  or  dis¬ 
cover  failures. 


A.  WHAT  KINDS  OF  MAINTENANCE  ARE  THERE? 

Let's  get  first  things  first.  What  kinds  of  maintenance  are 
there?  The  answer  depends  on  one's  breadth  of  view.  Certainly, 
there  is  preventive  maintenance  —  the  activity  intended  to  pre¬ 
vent  functional  failures  or  discover  them.  There  is  also  cor¬ 
rective  maintenance  —  the  activity  intended  to  return  failed 
equipment  to  operating  condition.  If  you  consider  the  modifica¬ 
tion  (alteration)  of  hardware  to  be  a  kind  of  maintenance,  then 
we  could  call  that  alterative  maintenance  —  an  activity  intended 
to  eliminate  failures  by  changing  design. 

This  handbook  addresses  only  preventive  maintenance. 


B.  WHAT  IS  A  FUNCTION? 

A  function  is  a  capability  of  a  system,  equipment,  or  lesser 
item  that  is  a  specific  requirement  of  the  design. 

There  are  two  kinds  of  functions  that  we  must  consider  when 
determining  preventive  maintenance  task  needs: 

•  On-line  —  Primary  functions  operated  either  continu¬ 
ously  or  so  often  that  the  user  has  current  knowledge 
about  their  state  (for  example,  the  function  provided  by 
the  boiler  feedwater  pumps) . 

•  Off-line  —  Primary  functions  operated  under  the  user's 

control  but  used  intermittently  or  so  infrequently  that 
their  availability  is  not  known  by  the  user  without  some 
special  check  or  test  (for  example,  the  functions 

provided  by  most  weapons) . 

Secondary  functions  that  are  hidden  from  the  user 
because  there  is  no  immediate  Indication  of  malfunction 
or  failure.  The  demand  for  such  functions  usually 
f ollow8  another  failure  (for  example,  the  functions 

provided  by  emergency  systems  and  automatic  protective 
devices) . 
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Often  some  pie^e  of  hardware  performs  several  functions. 
Some  may  be  so  sample  they  are  overlooked.  For  example,  the 
elements  of  any  fluid  system  have  the  elementary  function  of 
containing  the  fluid  as  well  as  controlling  its  flow  or  pressure. 
Systems  also  often  include  self-protective  and  information 
functions . 

We  must  also  recognize  that  functions  may  be  either  active 
(there  is  some  kind  of  output)  or  passive  (such  as  containment  or 
insulation) . 

In  your  analysis  to  determine  the  need  for  preventive 
maintenance  tasks,  you  will  review  each  function  of  a  system  to 
identify  its  dominant  failure  modes.  (These  functions  will 
include  objective  outputs  (including  status  reporting),  pro¬ 
tective  functions,  passive  functions,  and  output  interfaces  to 
other  systems.) 


C.  WHAT  IS  A  FAILURE? 

A  failure  is  simply  the  presence  of  an  unsatisfactory  con¬ 
dition,  a  condition  that  is  unsatisfactory  to  a  particular 
observer  in  a  specific  situation.  As  a  result,  if  failure 
information  is  to  be  of  the  most  value,  it  must  carry  with  it 
some  knowledge  about  the  relevant  conditions. 

A  watchstander  in  the  engine  room  may  often  observe  and 
record  the  failure  of  some  redundant  element  in  the  Fuel  Oil 
Service  System,  but  the  Captain  will  not  necessarily  be  conscious 
of  such  a  failure  as  long  as  the  propulsion  system  is  able  to 
meet  his  needs.  Therefore,  a  question  about  the  prevalence  of 
failures  of  this  kind  would  result  in  entirely  different  answers 
from  the  watchstander  and  the  Captain. 

Similarly,  the  "oil  kings”  on  different  ships  may  use  the 
Fuel  Oil  Service  System  in  such  different  ways  that  resultant 
instances  of  failure  are  very  different,  even  though  the  equip¬ 
ment  is  exactly  the  same. 

Our  primary  objective  is  to  maintain  function  as  perceived 
by  the  Captain,  not  by  the  watchstander. 


D.  FAILURE  DETECTION 

Failures  may  be  detected  while  performing  specific  operating 
duties,  or  by  casual  observation  by  the  crew,  or  they  may  be  dis¬ 
covered  as  the  result  of  a  specific  preventive  task.  Such 
failures  are  "functional  failures,"  the  inability  of  an  item 
(system-equipment-unit-part)  to  meet  a  specified  performance 
standard.  A  complete  loss  of  function  is  clearly  a  functional 
failure;  so  is  the  inability  to  perform  at  the  minimum  level 
defined  as  satisfactory. 


Having  defined  a  specific  functional  failure,  it  may  be 
practicable  to  identify  or  define  some  pre-failure  condition  that 
indicates  that  a  failure  is  imminent.  Such  a  condition  is  called 
"potential  failure.”  The  ability  to  define  and  detect  potential 
failures  is  a  very  important  part  of  modern  maintenance  program 
design.  (The  decrease  in  output  of  a  pump  or  a  radio  transmitter 
below  some  specific  performance  standard  are  examples  of 
potential  failures.) 

E.  CONSEQUENCES  OF  FAILURE 

The  most  important  consequence  of  a  failure  is  a  threat  to 
safety.  A  threat  to  safety  is  one  which  threatens  life,  limb,  or 
health  of  the  crew  or  others.  Threats  to  the  condition  of  equip¬ 
ment  are  not  included. 

The  next  most  important  consequence  of  a  failure  is  a  threat 
to  operational  capability.  Such  consequences  are  economic  in  the 
broad  sense.  Measures  of  such  consequences  must  include  the 
imputed  cost  of  lost  operational  capability.  Koep  in  mind  that 
if  a  system  that  provides  operational  capability  has  redundancy 
which  prevents  some  failures  from  causing  loss  of  system 
functions,  then  loss  of  operational  capability  is  not  a 
consequence  of  single  failures. 

Last  in  the  order  of  consequences  of  failure  is  a  threat  to 
functions  that  are  not  included  above.  Most  of  these  are  support 
functions.  Some  are  functions  that  provide  operational  capabil¬ 
ity  but  have  either  on-line  or  switching  redundancy.  (Failure  to 
understand  the  attributes  of  redundancy  is  a  common  error  among 
operating  personnel.) 

Failures  of  hidden  or  infrequently  used  functions  have  no 
immediate  consequences.  Nevertheless,  their  ultimate  conse¬ 
quences  may  have  a  severe  impact  on  safety  or  operational  capa¬ 
bility.  This  result  may  be  particularly  severe  if  the  hidden 
function,  in  fact,  provides  backup  for  what  otherwise  would  be  a 
saf ety-critical  or  operationally-critical  functional  failure. 


F .  FAILURE  DATA 

The  thirst  for  failure  data  appears  to  be  insatiable.  Yet, 
the  experience  of  the  professional  analyst  is  that  often  the  data 
being  collected  are  not  useful.  Since  it  is  absolutely  impracti¬ 
cable  to  collect  everything,  it  is  important  that  the  users  of 
data  present  an  ordered  list  of  the  information  needed  to  support 
their  work.  Developers  of  maintenance  programs  need  the  follow¬ 
ing  information  (placed  in  order  of  decreasing  failure  conse¬ 
quences)  : 

•  Failures  that  could  have  a  direct  effect  on  safety; 


•  Failures  that  have  a  direct  effect  on  operating  capabil¬ 
ity; 

•  Failure  modes  of  units  involved; 

•  Causes  of  potential  failures  (results  of  condition- 
directed  tasks); 

•  The  general  condition  of  unfailed  parts  in  units  that 
have  failed;  and 

•  The  general  condition  of  unfailed  systems. 

All  failure  data  must  be  accompanied  by  data  describing  the 
activity  of  che  unit  population.  To  be  useful  these  data  must: 

•  Be  complete  (include  all  failure  events  in  the  period 
analyzed) . 

•  Be  accompanied  by  an  appropriate  activity  (or  stress) 
parameter  (e.g.,  total  unit  operating  hours  during  the 
same  period) . 

•  Identify  specific  location  (if  there  are  multiple 
installations  in  a  ship). 

The  lack  of  information  of  this  quality  does  not  disable  RCM, 
but  it  reduces  its  benefits,  particulary  those  related  to 
improving  an  initial  program  based  on  operating  experience. 

NOTE : 

This  information  makes  the  calculation  of  unit  mean  time  between 
failures  (MTBF)  possible,  but  it  still  is  not  sufficient  to 
support  a  need  to  understand  the  effect  of  age  on  reliability. 
For  this  capability,  these  additional  data  are  required: 

•  Identification  of  each  failed  unit  (its  location  and 
serial  number) 

•  The  age  (cumulative  stress)  of  each  unit  installed  or 
removed 

•  Conditions  found  in  the  failed  units . 


G.  MULTIPLE  FAILURES 

Multiple  failures  are  a  specter  that  threatens  ship 
commanders.  Although  specters  are  immune  to  conventional 
weapons,  they  are  vulnerable  to  truth. 

Multiple  failures  are  of  two  kinds: 

•  The  occurence  of  more  than  one  independent  event;  and 

•  The  occurence  of  associated  events  (common  cause). 

We  are"  often  frightened  by  events  of  the  second  kind  and,  as  a 
result,  are  made  fearful  of  events  of  the  first  kind.  Keep  in 
mind  that  these  two  kinds  of  failures  have  nothing  in  common  but 
their  result. 
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The  probability  of  multiple  independent  failures,  even  if 
the  expected  failure  rate  is  moderately  high,  is  quite  low. 
Given  a  unit  failure  rate  of  1  failure  per  100  operating  days  and 
both  units  on-line,  the  expected  occurrence  of  2  failures  in  the 
same  operating  day  is  only  1  in  10,000! 

If  the  repair  time  for  the  first  failure  is  one  operating 
day  or  less,  even  a  potentially  critical  functional  failure  (both 
units  failed)  is  extremely  unlikely.  The  probability  of  multiple 
common  cause  failures  is  also  very  low,  provided  the  designer  had 
done  his  job  well,  considering  both  internal  and  external 
threats.  These  failures  depend  on  normally  unpredictable  events, 
ranging  all  the  way  from  careless  operations  to  Acts  of  God.  The 
message  is  very  simple.  Do  not  encumber  the  crew  with  doubtful 
preventive  maintenance  tasks  in  an  attempt  to  minimize  multiple 
failures.  In  your  zeal  to  do  so,  you  may  create  a  high  risk  of 
common  cause  failures  caused  by  maintenance  errors  while 
attempting  to  prevent  independent  failures. 

Common  cause  failures  are  not  likely  to  respond  to  a  preven¬ 
tive  maintenance  task. 

Of  course,  these  comments  relate  to  tasks  intended  to 
prevent  failures.  There  is  an  important  need,  when  system  design 
provides  redundancy,  to  be  assured  that  it,  in  fact,  exists. 
This  need  will  be  described  further  in  the  section  on  Failure- 
Finding  Tasks. 


H.  THE  FAILURE  PROCESS 

All  of  us  learn  to  accept  failures  as  a  part  of  living  with 
hardware.  In  some  cases,  it  is  easy  to  find  ways  to  eliminate 
failures  by  changing  design.  In  other  cases,  the  function  we  need 
requires  a  great  deal  of  complexity,  and  we  are  forced  to  accept 
a  high  failure  rate  as  a  trade-off  for  having  that  function,  even 
though  its  availability  may  be  less  than  we  would  like. 

The  role  of  preventive  maintenance  is  to  decrease  or  pre¬ 
vent  these  failures.  Let’s  make  sure  that  we  have  an  understand¬ 
ing  of  the  failure  process. 

If  we  can  visualize  that  a  simple  item  like  a  pump  shaft  or 
a  gear  has  a  quality  we  can  call  "resistance  to  failure"  and  that 
use  of  this  item  subjects  it  to  "stress",  then  "failure"  occurs 
when  the  stress  exceeds  the  resistance  to  failure.  Figure  Il-i 
presents  this  idea  graphically. 

Excess  resistance  to  failure  can  be  provided  by  excess 
material  that  wears  away,  or  is  consumed,  or  simply  provides 
extra  strength  that  is  subject  tb  loss  from  corrosion  or  fatigue. 
The  resistance  to  failure  of  simple  items  usually  decreases  with 
use  or  time  (age). 
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Stress  is  dependent  upon  use  and  may  be  highly  variable.  It 
may  increase,  decrease,  or  not  change  with  use  or  time.  If  you 
reviewed  the  failures  of  a  large  number  of  nominally  identical 
simple  items,  you  would  very  likely  find  they  had  about  the  same 
age  at  failure  and  that  these  failures  occurred  for  the  same 
reason.  You  can  see,  if  we  are  considering  preventive 
maintenance  for  some  simple  item  and  can  in  some  way  measure 
resistance  to  failure, we  can  use  that  information  to  help 
select  a  preventive  task. 

Now  let's  consider  a  very  complex  unit  that  consists  of 
hundreds  of  interacting  simple  items  (parts)  and  has  a  con¬ 
siderable  number  of  failure  modes.  In  this  case,  the  mechanism 
of  failure  is  the  same,  but  it  is  operating  simultaneously  and 
interactively  on  all  these  parts  so  that  failures  no  longer  occur 
for  one  reason  or  at  about  the  same  age.  For  these  units,  it  is 
likely  that  an  effective  task  can  be  designed  only  when  there  are 
a  few  dominant  or  critical  failure  modes. 

If  these  dominant  or  critical  failure  modes  can  be  elimi¬ 
nated  by  some  change  in  design,  then  the  previously  effective 
task  will  no  longer  be  effective  and  the  maintenance  program 
designer  must  look  elsewhere. 


*0r  something  that  is  highly  correlated  to  it. 
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Figure  H-l 

THE  FAILURE  PROCESS 


SUMMARY 


1.  Preventive  maintenance  Is  an  activity  intended  to  prevent 
functional  failures  or  discover  them. 

2.  A  function  is  a  capability  of  a  system,  equipment  or 
lesser  item  that  is  a  specific  requirement  of  the  design. 

3.  Functions  can  be  on-line  or  off-line,  active  or  passive. 

4.  A  failure  is  the  presence  of  an  unsatisfactory  condition. 

5.  Failures  may  be  detected  while  performing  specific 
operating  duties,  by  casual  observation,  or  by  specific  failure¬ 
finding  tasks. 

6.  The  most  important  consequence  of  failure  is  a  threat  to 
safety.  Next  most  important  is  a  threat  to  operating  capability. 

7.  Available  failure  data  often  are  not  useful  to  support 
maintenance  program  design  adequately. 

8.  The  threat  of  multiple  failures  is  often  overestimated. 

9.  Failures  result  when  stress  exceeds  resistance  to 
failure.  For  complex  systems  or  equipment,  the  multiplicity  of 
parts  and  failure  modes  often  causes  failures  to  occur  over  a 
wide  range  of  ages,  reducing  or  eliminating  the  potential 
effectiveness  of  preventive  maintenance. 
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III.  PREVENTIVE  MAINTENANCE  TASKS 


We  do  preventive  maintenance  (PM)  because  wo  believe  that 
doing  some  task  in  accordance  with  a  predetermined  plan  or 

specification  will  prevent  or  discover  hardware  failures  before 
they  have  en  impact  on  safety,  or  operetione  or  some  important 
•upport  function#  This  plan  or  apeclflcatlon  haa  at  leaet  two 
elemental  what  and  whan.  It  may  alio  include  who,  where,  why  and 
how. 

Thla  aectlon  of  the  handbook  addreeeea  the  kinde  of 

preventive  taeke  available  to  you  and  their  ipeciflc  application. 

The  whole  idea  of  preventive  maintenance  reete  on  the  belief 
that,  all  thinga  conaidered,  the  user  will  be  better  off  by  doing 

a  PM  taak  than  by  not  doing  it.  The  Navy  will  be  better  off  if 

either  the  taek  effectively  prevents  failures  affecting  safety, 
or,  for  all  other  failures,  it  provides  benefits  that  exceed  the 
cost.  (Of  course,  cost  in  this  case  Includes  the  Imputed  cost  of 
lost  mission  capability.) 

What  are  the  potential  preventive  maintenance  processes? 
When  considering  the  prevention  of  a  functional  failure  we  have 
three  alternatives! 

e  Select  a  time-directed  task; 

e  Select  a  condition-directed  task;  or 

e  Do  nothing. 

It  it  is  not  practicable  to  prevent  a  functional  failure  and 
that  failure  is  not  evident  to  the  crew  during  normal  operations, 
we  have  an  additional  alternative! 

e  Select  a  failure-finding  task  to  discover  the  failure. 


A.  TIMS-DXRSCT2D  TASKS 

A  time-directed  taak  is  one  performed  at  a  specific  Interval 
without  consideration  of  other  variables.  The  task  interval  may 
be  either  a  specific  period  of  time  or  one  determined  by  the 
number  of  certain  events  since  some  previous  action.1  The  task 
may  require  either  specific  action  resulting  in  continued  use  or 


1  Rounds  fired,  for  example 
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reuse  (RW-rework),  or  specific  action  requiring  that  the  item  be 
discarded  and  replaced  with  a  new  item  of  the  same  kind  (LL-life 
limit) . 

Examples;  Remove  the  RADAR  ANTENNA  for  rework  (RW)  annual¬ 
ly. 

Replace  the  PERSONNEL  BOAT  ENGINE  LUBE  OIL  FILTER 
(LL)  every  500  operating  hours. 


B.  CONDITION-DIRECTED  TASKS 

A  condition-directed  task  (CD)  is  one  performed  at  a  speci¬ 
fic  interval  (or  after  a  number  of  specific  events)  that  compares 
observed  condition(s)  with  an  appropriate  standard. 

Example;  Inspect  the  CHILLED  WATER  CIRCULATING  PUMP  for 
external  leaks  weekly  (CD).  No  leaks  permitted. 


C.  FAILURE-FINDING  TASKS 

A  failure-finding  task  (FF)  is  one  performed  at  a  specific 
interval  to  find  functional  failures  that  have  occurred  but  are 
not  evident  to  the  operating  crew. 

Unlike  the  previously  described  kinds  of  tasks,  failure¬ 
finding  tasks  do  not  prevent  functional  failures;  they  discover 
them.  They  are  preventive  only  in  the  general  sense  that  they 
prevent  surprises  by  revealing  failures  of  hidden  or  infrequent- 
ly-used  functions. 

Example;  Test  the  STEERING  CONTROL  SYSTEM  AUTOMATIC 
CHANGEOVER  TRANSFER  SWITCH  quarterly. 


D.  TASK  SELECTION 

Each  task  selected  must  meet  two  requirements: 
e  It  must  be  applicable;  and 
e  It  must  be  effective. 

Applicability  depends  on  failure  characteristics.  An  applicable 
task  must  either  prevent  or  reduce  the  Impact  of  failures.  (An 
inapplicable  task  may  in  reality  Increase  failures,  or  simply 
have  no  effect.)  Effectiveness  measures  result  and  depends  on 
failure  consequences .  Figure  III-l  summarizes  the  applicability 
and  effectiveness  criteria  for  all  of  the  task  alternatives  dis¬ 
cussed  above. 


E.  SERVICING  AND  LUBRICATION 

Servicing  and  lubrication  tasks  may  be  either  time-directed 
or  condition-directed.  These  tasks  can  be  identified  by  use  of 
the  RCM  logic;  in  fact,  the  logic  may  identify  some  special 
servicing  or  lubrication  need.  The  RCM  process  requires  a  common 
sense  review  of  existing  requirements  and  a  review  of  the 
manufacturer's  recommendations  to  be  sure  that  all  of  the  ship's 
requirements  are  identified  and  excessive  needs  are  deleted. 

The  ability  to  evaluate  servicing  and  lubrication  require¬ 
ments  depends  greatly  on  the  availability  of  "conditions  found" 
information.  If  you  lack  this  information,  you  will  have 
difficulty  specifying  applicable  and  effective  servicing  and 
lubrication  tasks. 


F.  GENERAL  INSPECTIONS 

As  originally  developed  for  application  to  aircraft,  the  RCM 
process  provided  for  a  set  of  general  inspections.  These  were 
called  "zonal"  inspections  because  they  were  directed  to  areas 
and  spaces  which  together  exhaustively  covered  the  entire  air¬ 
craft.  Zonal  Inspections  provided  a  means  for  aggregating  minor 
inspections  of  all  kinds  that  were  within  the  capabilities  of  any 
journeyman  mechanic.  (In  most  cases,  these  inspections  could  be 
considered  to  be  integrity  inspections  such  as  checks  for  leaks, 
overheating,  broken  hardware,  etc.) 

In  Navy  ships,  a  somewhat  different  situation  exists: 

•  The  crew  occupy  or  frequently  visit  most  of  the  ship's 
spaces  during  operation,  and 

•  There  is  already  a  process  for  assuring  the  general  con¬ 
dition  of  all  spaces  and  availability  of  damage  control 
equipment . 

Therefore,  the  zonal  inspection  process,  a  normal  part  of  an 
RCM-oriented  preventive  maintenance  program  for  aircraft,  is  not 
applied  to  ships. 
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Figure  III-l 

TASK  APPLICABILITY  AND  EFFECTIVENESS  CRITERIA 


TASK 

APPLICABILITY 

EFFECTIVENESS 

Time-Directed 

Scheduled  Rework 

(RW) 

Probability  of  failure  must 
increase  at  an  identifiable 
age.  A  large  proportion  of 
units  must  survive  to  that 
age. 

For  critical  failures:  The  task 
must  reduce  the  risk  of  fail¬ 
ure  to  an  acceptable  level. 

For  all  other  failures:  The 
task  must  be  cost-effective. 

Scheduled  Life  Limit 

(LL) 

For  safe-life  items:  Probabil¬ 
ity  of  failure  below  life  limit 
must  be  zero. 

A  safe-life  limit  must  reduce 
the  risk  of  failure  to  an  ac¬ 
ceptable  level. 

For  economic-life  items: 
Probability  of  failure  must 
increase  at  an  identifiable 
age.  A  large  proportion  of 
units  must  survive  to  that 
age. 

An  economic-life  limit  must 
be  cost-effective 

Condition-Directed 

(CD) 

Reduced  failure  resistance 
for  a  specific  failure  mode 
must  be  detectable.  Rate  of 
change  in  failure  resistance 
must  be  reasonably  pre¬ 
dictable. 

For  critical  failures:  The  task 
must  reduce  the  risk  of  fail¬ 
ure  to  an  acceptable  level. 

For  all  other  failures.  The 
task  must  be  cost-effective. 

Failure-Finding 

(FF) 

Occurrence  of  functional 
failure  must  not  be  evident 
to  the  operating  crew  during 
performance  of  their  normal 
duties. 

The  task  must  increase 
availability  of  the  affected 
function  to  an  acceptable 
level. 
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SUMMARY 


1.  There  are  three  alternatives  when  considering  prevention 
of  a  functional  failure: 

•  Select  a  time-directed  task; 

•  Select  a  condition-directed  task;  or 

•  Do  nothing. 

2.  If  a  specific  failure  is  not  evident  to  the  crew  and 
cannot  be  prevented,  there  is  an  additional  alternative: 

•  Select  a  failure-finding  task 

3.  Each  selected  task  must  be  both  applicable  and  effective. 

4.  Although  the  RCM  logic  will  obviously  bring  some  servic¬ 
ing  and  lubrication  tasks  to  mind,  these  can  be  entered  in  the 
se»*vicing  and  lubrication  analysis  which  requires  review  of  the 
manufacturer's  recommendations,  or  previous  PM  tasks. 

5.  General  (area)  inspections  used  in  aircraft  RCM  applica¬ 
tions  are  not  used  in  ships. 
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IV.  THE  APPLICATION  OF  RCM 


RCM  Is  a  methodology  intended  for  use  in  developing  the  pre¬ 
ventive  maintenance  tasks  which,  together,  comprise  the  preven¬ 
tive  maintenance  program  for  a  ship.  If  you  are  involved 
directly  in  the  application  of  RCM,  you  should  understand  that 
intention.  Otherwise,  you  may  focus  on  some  lesser  level  of 
assembly  and  its  function  rather  than  on  how  it,  in  concert  with 
other  hardware,  provides  all  the  functions  of  the  ship.^ 

If  you  recognize  that  safety  transcends  mission,  and  mission 
transcends  support  functions,  then  you  will  understand  that  for 
each  of  these,  different  levels  of  effectiveness,  and  perhaps 
resources,  should  be  required. 

You  will  obtain  the  most  effective  results  by  working  as 
closely  as  possible  with  associated  system  specialists  who  also 
understand  the  "ship  objective."  This  close  association  can  be 
achieved  either  physically  or  by  active,  perceptive,  communica¬ 
tive  management  of  separate  activities. 

Experience  has  highlighted  the  critical  importance  of: 

•  Careful  initial  identification  and  partitioning  and  easy 
ways  to  amend  the  initial  system  and  subsystem 
boundaries; 

•  Initial  discussion  between  the  developers  and  the  In 
Service  Engineering  Agents  (ISEA)  to  obtain  the  ISEA's 
insights  and  ensure  that  the  analysis  gets  off  on  the 
right  track; 

•  Selecting  analysts  who  have  a  tenacious  curiosity  about 
how  things  work,  why  they  exist,  and  what  PM  tasks  really 
are  applicable  and  effective;  and 

•  Independent  quality  assurance  reviews. 


A.  ANALYST  AND  STAFF  SELECTION  AND  TRAINING 

The  ideal  staffing  for  applying  RCM  recognizes  the  need  for 
3  specific  skills. 

•  An  understanding  of  the  system's  design  from  the  view¬ 
point  of  the  designer  (an  engineer). 

•  An  understanding  of  how  the  system  is,  or  will  be,  used, 
and  of  its  dominant  failures  and  operating  characteris¬ 
tics  (a  ship's  work  center  supervisor). 


1  This  is  a  common  error 
applying  RCM. 


by  inexperienced  analysts  when 
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•  An  understanding  of  In-service  reliability  analysis  and 
preparation  of  maintenance  requirements  documents  (a 
reliability  analyst). 

The  most  effective  applications  of  RCM  result  when  persons 
having  these  skills  work  together.  An  effective  way  to  achieve 
this  objective  is  to  assign  two  man  engineer/technician  teams  to 
work  on  systems  familiar  to  them  and,  if  practicable,  locate  them 
at  the  hardware  site.  The  third  skill  can  be  provided  by  a 
specialist  who  serves  all  teams  on  a  particular  project. 

The  staff  also  should  Include  an  independent,  technically 
qualified  person  who  reviews  all  documents  to  ensure  that  they 
are  technically  correct  and  comply  with  the  applicable  standards 
and  specifications. 

Preparing  an  RCM-based  preventive  maintenance  program 

requires  training  in  RCM  concepts  and  in  use  of  the  documentation 
specified  in  MIL-P-24534A.  It's  also  important  that  you  and 
other  members  of  your  team  be  very  familiar  with  the  design, 
operating  characteristics  and  operating  experience  of  the  systems 
assigned. I  Arrange  for  periodic  meetings  of  all  teams  on  your 
project  to  discuss  ideas  and  problems  associated  with  each 

documentation  step  in  the  RCM  process.  These  meetings  will 

accelerate  the  learning  process  and  avoid  many  potential  pitfalls 
that  may  occur  as  you  work  on  your  assigned  system(s). 

Do  not  use  existing  Planned  Maintenance  System  (PMS) 
documentation  as  a  training  resource. ^  Preparing  an  RCM-based 
program  is  Intended  to  be  an  innovative,  creative  search  for 

applicable  and  effective  tasks.  You  will  do  a  better  job  by 
thinking  about  what  should  be  done  than  by  reviewing  the  PM  tasks 
that  are  being  done  on  the  system(s)  to  which  you  are  assigned. 


*  If  you  feel  you  need  more  knowledge  about  preventive 
maintenance,  see  Nowlan  and  Heap,  Reliability-Centered 
Maintenance  DDC  AD  4066579,  1979. 

*  Retrofitting  an  RCM-based  program  on  an  existing  ship  class 
will  require  access  to  this  documentation  as  a  means  for 
identifying  failure  modes  ONLY,  not  for  training  or 
familiarisation  purposes. 
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B.  INFORMATION  COLLECTION 


Technical  information  la  required  for  each  chip  eyatem  and 
ita  equipment#. 

e  Descriptive  information 
__  Narrative  descriptions 
'  Design  specifications 

_  System  schematics  (including  Interfaces  with  other 

systems) 

__  Assembly  drawings 

_  Field  and  engineering  changes 

e  Operating  information 

__  Operating  and  maintenance  instructions 
'  Condition  and  performance  standards 
___  Failure  data 

_____  Existing  Maintenance  Index  Pages  (MIF)  and  Maintenance 
Requirement  Cards  (MRC)  (for  use  as  a  source  of 
information  after  tasks  have  been  identified  and  for 
identifying  failure  modes  and  functional  failures  for 
retrofit  applications) 

Acquisition  and  distribution  of  this  information  is  best 
handled  as  a  specific  assignment  under  the  direction  of  the 
Project  Manager.  This  work  requires  a  high  level  of  knowledge 
about  the  most  useful  sources  of  this  information  and  the 
processes  by  which  it  can  be  most  expeditiously  obtained  for  the 
various  kinds  of  systems  and  equipments  Involved. 


C.  SYSTEM  IDENTIFICATION  AND  PARTITIONING 

Your  first  task  is  to  identify  all  of  the  ship’s  systems  and 
partition  them  in  a  logical  way.  The  Ship  Work  Authorization 
Boundaries1  will  be  used  to  identify  all  ship  systems.  (See 
Table  IV-1. )  A  further  breakdown  of  these  systems  to  the  equip¬ 
ment  level  will  be  required.  The  Ship  Systems  Definition  and 
Index  (SSDI)  prepared  for  the  FFG-7  class  ships  is  a  typical 
example  of  what  must  be  done  (See  Figure  IV-1.) 

This  breakdown  must  be  done  for  the  ship,  not  separately  for 
each  SWAB  Group,  otherwise  there  is  a  high  risk  of  gaps  and  over¬ 
laps.  A  system  is  "a  set  or  arrangement  of  things  so  related  or 
connected  as  to  form  a  unity  or  organic  whole. This  defini¬ 
tion  permits  two  quite  different  perceptions  —  unity  as  a 


1  NAVSEA  09 00-LP-09 8-6010  (for  surface  ships) 

2  Hew  World  Dictionary,  Second  College  Edition 
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collection  of  like  things  (e.g.,  a  collection  of  all  antennas)  or 
an  organic  assembly  (e.g.,  a  fuel  system).  Given  a  choice,  you 
will  find  that  the  organic  approach  simplifies  analysis.  It 
links  inputs  to  outputs.  The  collection  approach  may  put  inputs 
in  one  system  and  outputs  in  another.  If  you  find  that  the  SWAB 
is  inappropriate  for  logical  analysis,  propose  an  appropriate 
breakdown  for  use  in  your  task  to  your  PMS  Coordinating  Activity. 

No  matter  how  you  finally  decide  to  structure  each  system, 
be  sure  that  you  (the  analyst)  and  the  final  technical  reviewer 
agree  on  the  content  and  structure  of  each  system  before  you  go 
any  further. 


TABLE  IV-1 

SHIP  WORK  BREAKDOWN  STRUCTURE 


SWAB 

Group 

Nomenclature 

General  Scope 

100 

Hull  Structure 

Ships  structure  Including 
decks,  stacks,  foundations, 
and  superstructure. 

200 

Propulsion  Plant 

Systems  and  subsystems  to 
support  propulsion. 

300 

Electric  Plant 

Electrical  generation  and 
distribution  equipment. 

400 

Command  and 
Surveillance 

Systems  for  command  control, 
navigation,  tracking  and  fire 
control. 

500 

Auxiliary  Systems 

Fluid,  electromechanical,  air 
conditioning  and  ship  support 
systems . 

600 

Outfit  and 

Furnishing 

Habitational  and  sanitary 
systems,  furnishings,  and 
services . 

700 

Armament 

Offensive  and  defensive  weapon 
systems . 
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THIS  ELEMENT  INCLUDES  UNITARY  REFRIGERATION  FOR 
SHIP  AIR  CONDITIONING  SYSTEMS 


Figure  IV- 1 

SAMPLE  FFG-7  SSDI  PAGE 
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D.  ANALYSIS  OF  SYSTEMS 

The  RCM  method  requires  analysis  of  preventive  maintenance 
requirements  at  the  system  and  subsystem  levels.  The  need  for 
analysis  below  the  subsystem  level  depends  on  the  complexity  of 
the  system  and  your  knowledge  and  expertise. ^  You  will  do  less 
"dog  work"  if  you  do  not  go  below  the  subsystem  level.  Neverthe¬ 
less,  understanding  all  of  the  functions  of  a  complex  system  and 
selecting  applicable  and  effective  tasks  to  maintain  them  may 
require  that  you  go,  selectively,  to  the  equipment  level  or 
below.  You  will  do  fewer  of  these  lower  level  analyses  as  you 
become  more  expert. 

Keep  in  mind  that  the  system  level  often  provides  an  oppor¬ 
tunity  for  operational  checks  (condition-directed  or  failure¬ 
finding  tasks)  that  are  very  effective.  Do  not  overlook  this 
opportunity. 


E.  DEFAULT  STRATEGY 

If  you  have  limited  operational  knowledge  about  a  particular 
functional  failure,  you  may  lack  confidence  about  your  ability  to 
answer  a  question  in  the  RCM  Decision  Logic  Tree. 

The  default  strategy  describes  how  you  should  act  if  you 
feel  that  you  have  Inadequate  information  on  which  to  decide  upon 
the  need  for  a  task.  The  idea  is  that  if  you  cannot  make  a  final 
decision,  you  make  an  interim  one  that  minimizes  risk.  Later, 
you  can  update  it  when  you  have  more  knowledge.  The  default 
strategy  for  each  of  the  decision  tree  questions  is  shown  in 
Figure  IV-2. 


1  If  you  believe  that  for  any  system  you  must  analyze  the 
functions  of  each  equipment  item,  you  have  the  wrong 
perspective.  Reread  the  first  paragraph  of  Chapter  A. 
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Figure  IV-2 

DEFAULT  STRATEGY 


DECISION  QUESTION 

DEFAULT  ANSWER 

1 .  Is  the  occurrence  of  a  failure  evident  to 
the  operational  crew  while  it  is  per¬ 
forming  its  normal  duties? 

No — (except  for  critical  secondary  dam¬ 
age).  This  answer  classifies  functions  as 
hidden  or  infrequent. 

2.  Does  the  failure  cause  a  loss  of  func¬ 
tion  or  secondary  damage  that  has  a 
direct  and  adverse  effect  on  operating 
safety? 

Yes— This  answer  classifies  functions  as 
critical. 

3.  Does  the  failure  have  a  direct  and  ad¬ 
verse  effect  on  operational  capability? 

Yes- This  answer  classifies  functions  as 
operational. 

4.  Is  there  an  applicable  and  effective 
preventive  maintenance  task  (or  com¬ 
bination  of  tasks)? 

Yes — if  the  potential  task  is  a  CD  task. 
Make  the  task  interval  short  enough  to  be 
effective. 

No— if  the  potential  task  is  a  rework  or 
discard  task  and  safety  is  not  involved. 

Yes — if  the  potential  task  is  a  rework  or 
discard  task  and  safety  is  involved. 

F.  PERIODICITY 

Although  numerous  ways  have  been  proposed  for  determining 
the  correct  periodicity  of  preventive  maintenance  tasks,  none  are 
practicable,  unless  you  know  the  in-service  age-reliability 
characteristics  of  the  system  or  equipment  affected  by  the 
desired  task.  This  information  is  not  generally  available  for 
ship  systems  and  equipment. 

Careful  analyses  of  similar  kinds  of  hardware  in  the 
commercial  airline  community  have  shown  that,  overall,  more  than 
90%  of  the  hardware  analyzed  had  no  adverse  age-reliability 
relationship.  This  does  not  mean  that  individual  parts  do  not 
wear;  they  do.  It  means  that  the  ages  at  failure  are  distributed 
in  such  a  way  that  there  is  no  value  in  imposing  a  preventive 
maintenance  task.  In  fact,  in  a  large  number  of  cases,  imposing 
a  so-called  preventive  task  actually  increases  the  average 
failure  rate. 
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If  you  are  convinced  that  a  periodic  preventive  maintenance 
task  is  necessary,  it  is  unlikely  that,  from  the  available 
information,  you  can  select  the  best  periodicity.  Do  not  fall 
into  a  trap  by  believing  that  the  failure  rate,  or  its  inverse, 
the  Mean  Time  Between  Failure  (MTBF),  is  a  proper  basis.  It  is 
not.  Why?  Because  it  does  not  give  you  any  information  about 
the  effect  of  increasing  age  on  reliability.  It  only  gives  you 
the  average  age  at  which  failure  occurs.  The  best  thing  you  can 
do  if  you  lack  good  information  about  the  effect  of  age  on 
reliability  is  to  pick  a  periodicity  that  seems  right.  Later, 
you  can  personally  explore  the  characteristics  of  the  hardware  at 
hand  by  periodically  increasing  the  periodicity  and  finding  out 
what  happens.  Chances  are  that  in  most  cases  you'll  be  able  to 
make  significant  increases  without  adverse  results.^-  When  you 
want  to  establish  the  periodicity  of  a  failure-finding  task,  some 
assumptions  about  the  failure  distribution  of  the  affected  hidden 
or  infrequent  function  make  the  calculation  somewhat  simpler. 2 
Here  is  a  suggested  solution: 

T  =  -9  logg  (2A-1)  where:  T  is  the  task  periodicity 

Q  is  the  no-task  MTBF 
A  is  the  desired/expected 
availability 

Example: 

No-task  MTBF  *  50  hours  (an  estimate) 

Desired/expected  availability  =  .95 

Task  periodicity  (T)  =  -50  loge  [(2  x  .95)  -1] 

=  -50  loge  .90 
»  5  hours 

NOTE: 

This  solution  assumes  exponential  survival  and  no  adverse  impact 
of  test  on  future  reliability.  If  the  test  actually  degrades 
reliability,  then  the  testing  interval  should  be  longer. 


^  This  practice  is  obviously  not  to  be  used  when  failures  have 
a  direct  adverse  effect  on  safety;  then  a  controlled  test  is 
required. 

2  Assumes  that  the  availability  of  the  function  decreases  at  a 
constant  rate  (exponentially). 
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G. 


ECONOMICS  AND  COST  EFFECTIVENESS 


This  section  of  the  handbook  has  made  several  references  to 
economics  and  cost  effectiveness .  Those  words,  while  commonplace 
in  a  commercial  environment,  are  relatively  unfamiliar  with  the 
military  environment.  Nevertheless,  they  underlie  some  of  the 
most  powerful  decisions  associated  with  the  selection  and  design 
of  weapons  and  support  systems.  Keep  in  mind  that  the  ship  has  a 
particular  system  because  of  a  cost/benefit  decision.  You  may 
not  be  able  to  find  the  numbers  neatly  set  down  anywhere,  but  set 
down  or  not,  they  existed  at  some  time  in  the  mind  of  a  decision¬ 
maker. 

If  you  are  charged  with  the  responsibility  for  designing  a 
maintenance  program  or  selecting  a  preventive  maintenance  task, 
you  have  a  similar  responsibility.  Remember  this  statement  from 
Section  III  of  this  handbook: 

The  whole  idea  of  preventive  maintenance  rests  on 
our  belief  that,  all  things  considered,  the  user 
will  be  better  off  doing  a  PM  task  than  by  not 
doing  it. 

Note  that  the  task  must  make  the  user,  not  the  analyst , 
better  off. 

We've  already  established  the  critical  importance  of 
failures  that  are  a  threat  to  safety.  Assurance  that  a  ship  and 
its  systems  are  safe  has  sufficient  value  that  we  exclude  effec¬ 
tive  safety-related  tasks  from  our  economic  considerations. 

For  non-safety-related  functions  or  functional  failures,  we 
must  consider  economics.  We  do  this  in  the  form  of  trade-offs, 
the  idea  being  to  decide  whether  the  user  will  be  better  off  by 
doing  a  PM  task  than  by  not  doing  it. 

Our  measure  is  called  cost-effectiveness .  Cost-effective¬ 
ness  is  a  measure  of  the  efficiency  of  our  use  of  resources  to 
obtain  some  benefit;  it  is  not  just  a  case  of  being  cheap. 

When  you  make  these  trade-offs,  these  ideas  should  be  help¬ 
ful: 

•  Your  application  of  economics  will  not  require  a  great 
deal  of  precision.  Most  of  your  work  will  simply  consist 
of  finding  the  alternative  which  is  biggest,  or  smallest, 
not  how  big  it  is; 
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•  For  mission-related  functions,  if  you  are  convinced  that 
a  task  is  applicable  (that  is,  you  know  that  it  works)* 
and  the  periodicity  required  to  make  it  effective  is 
practicable,  you've  probably  got  a  good  task;  and 


For  a  non-miss ion- related  function,  if  you  are  convinced 
that  the  task  is  applicable,*  using  the  required 
periodicity,  estimate  the  annual  cost  of  doing  the  task 
and  compare  it  with  the  annual  direct  cost  of  failures 
you  expect  to  prevent. 


*  Review  Figure  III-l 
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V.  DEVELOPING  A  PREVENTIVE 
MAINTENANCE  PROGRAM 


In  previous  chapters  we  have  discussed  a  wide  range  of 
things  —  history,  principles,  kinds  of  tasks  —  but  we  have  not 
yet  addressed  any  method  for  using  the  knowledge  we  have 
acquired.  If  you  can  keep  what  has  already  been  discussed 
clearly  in  mind,  it  can  improve  your  ability  to  develop  mainte¬ 
nance  programs;  but  an  important  piece  of  the  puzzle  Is  still 
missing.  We  need  an  orderly  method  for  using  the  knowledge  we 
now  have  about  preventive  maintenance. 

We  will  build  a  list  of  functional  failures  and  failure 
modes  by  describing  each  system/subsystem,  and  listing  its 
functions  (both  evident  and  hidden),  its  input  and  output 
interfaces,  and  its  functional  failures.  For  complex  systems/ 
subsystems  we  may  break  some  lesser  items  out  separately  to 
obtain  similar,  more  detailed,  information  for  each  of  these 
items . 

When  directed  by  the  PMS  Coordinating  Activity,  we  may  use 
the  existing  PM  tasks  as  input  to  our  analysis,  identifying  for 
each  system,  all  of  the  functional  failures  and  the  failure  modes 
(and  their  effects)  that  each  existing  task  is  intended  to  pre¬ 
vent  or  control. 


A.  DESIGNING  AN  RCM-BASED  PREVENTIVE  MAINTENANCE  PROGRAM 
(MIL-P-24534A) 

The  process  for  designing  a  preventive  maintenance  program 
using  RCM-based  methodology  is  shown  in  Figure  V-l.  The 
following  steps  are  required: 

•  Master  Systems  and  Subsystems  Index; 

•  Functional  Failure  Analysis; 

•  Additional  Functionally  Significant  Item  Selection; 

•  Functionally  Significant  Items  Index; 

•  Failure  Modes  and  Effects  Analysis; 

•  Decision  Logic  Tree  Analysis; 

•  Servicing  and  Lubrication  Analysis; 

•  Maintenance  Requirements  Index; 

•  Task  Definition;  and 

•  Safety-Related  Design  Change  Recommendation. 
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RCM  APPLICATIONS  TO  SHIP/SYSTEMS 


Figure  V-l  I 

PM  PROGRAM  DESIGN  FLOWCHART 


B.  MASTER  SYSTEMS  AND  SUBSYSTEMS  INDEX  (OPNAV  4790/114)1 

Developing  a  preventive  maintenance  program  at  the  ship 
level  requires  that  a  master  index  be  prepared  so  there  is  a 
means  for  making  a  set  of  mutually  exclusive  and  exhaustive 
development  assignments.  The  Master  Systems  and  Subsystems  Index 
is  based  on  the  Ship  Work  Authoriziation  Boundaries  previously 
shown  in  Figure  IV-12.  If  a  Ship  Systems  Definition  and  Index 
(SSDI)  or  Ship's  System  Staging  Diagram  (SSSD)  has  been  prepared 
for  the  ship,  it  should  be  the  source  used  to  prepare  this 
index. ^ 

After  development  assignments  have  been  made,  it  is  likely 
that  this  index  (and  the  related  source)  will  require  revision  as 
the  result  of  additional  information  obtained  by  analysts  during 
the  development  process.  The  usual  causes  for  these  revisions 
are: 

•  A  system  contains  different  equipments  than  those  shown 
in  the  SSDI/SSSD; 

•  Equipments  have  been  shown  in  the  wrong  system;  or 

•  A  system  was  perceived  as  a  "set  of  things”  (such  as 
antennas)  rather  than  as  a  source  of  functions. 

These  revisions  should  be  discussed  with  your  PMS  Coordina¬ 
ting  Activity. 

C.  FUNCTIONAL  FAILURE  ANALYSIS  (OPNAV  4790/116) 

The  Functional  Failure  Analysis  (FFA)  is  required  for  RCM 
applications.  You  will  prepare  an  FFA  for  each  system  and 
subsystem  listed  in  the  Master  Systems  and  Subsystem  Index.  Its 
purpose  is  to  provide  a  description  of  each  system  and  subsystem, 
to  identify  all  functions  and  interfaces  with  other  systems  and 
to  identity  all  functional  failures  (including  failures  of  output 
interfaces) . 

If  a  system  is  simple  (no  subsystem  breakdown  necessary) 
only  a  single  FFA  is  required.  This  FFA  will,  then,  completely 
describe  the  characteristics  of  the  system  that  must  be 
considered  for  potential  preventive  maintenance  tasks. 


1  This  is  the  OPNAV  form  number. 

2  NAVSEA  0900-LP-098-6010 

^  Some  changes  may  be  necessary  to  facilitate  analysis. 
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If  a  system  includes  subsystems  which  in  themselves  are  at 
least  as  complex  as  the  system  discussed  above,  you  will  prepare 
PFA's  for  the  system  and  for  each  of  its  subsystems.  Before 
attempting  to  prepare  these  FFA*s,  prepare  (or  obtain)  a  block 
diagram  that  shows  the  functional  elements  of  the  entire  system 
and  the  Interfaces  between  it  and  other  systems.  Be  sure  that 
you  understand  which  functions  are  unique  to  each  subsystem  and 
which  functions  are  provided  by  the  system  as  a  whole. 

This  analysis  requires  a  brief  narrative  description  and 
specific  identification  of  design  features  that  provide  redun¬ 
dancy,  protective  devices,  or  other  fail-safe  design  provisions. 
Identification  of  Built-In  Test  Equipment  (BITE)  or  condition 
indicators  is  also  required.  Keep  in  mind  that  your  purpose  is 
to  learn  enough  about  each  system  to  lead  you  to  potential 
sources  of  system  functional  failures. 

Each  system  or  subsystem  can  have  one  or  more  functions. 
Identification  of  all  functions  requires  careful  study. ^  Make 
sure  that  you  are  not  overlooking  important  passive  functions. 
(A  fluid  system  that  provides  a  supply  of  water  also  holds  it.  A 
leak  is  a  failure!).  It  is  important  to  recognize  that  loss  of  a 
passive  function  may  be  significant,  even  though  the  system  may 
not  be  operating  at  the  time  of  failure. 

A  functional  failure  exists  when  a  system  or  subsystem 
ceases  to  provide  a  required  function.  Note  that  some  functions 
are  active  (loss  of  the  required  activity  constitutes  failure) 
while  some  are  passive  (activity  constitutes  failure).  For 
example,  a  centrifugal  pump  can  fail  by  not  providing  fluid  flow 
at  some  rate  and  pressure  (failure  of  an  active  function);  it  can 
also  leak  (failure  of  a  passive  function).  Include  failures  of 
both  kinds  in  this  analysis. 

The  definition  of  what  constitutes  a  failure  is  of  primary 
Importance.  Whenever  a  failure  is  defined  by  some  level  of  per¬ 
formance,  condition,  or  dimension,  the  appropriate  standard  must 
be  stated  to  provide  the  basis  for  establishing  whether  a  failure 
has  occurred. 


D.  ADDITIONAL  FUNCTIONALLY  SIGNIFICANT  ITEM  SELECTION 
(OPNAV  4790/117) 

For  new  ships  or  systems,  all  systems  and  subsystems  listed 
in  the  Master  Systems  and  Subsystems  Index  are  Functionally 
Significant  Items  (FSIs).  You  may  select  other  FSI  candidates 
from  lower  indenture  levels  by  review  of  the  system  block  diagram 


1  Be  sure  to  include  self-protective  and  information 
functions . 
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and  validate  these  by  using  the  Additional  FSI  Selection  form. 
Careful  completion  of  Lhe  FFAs  should  provide  you  with  the 
knowledge  necessary  for  making  additional  FSI  selections. ^ 

When  you  have  completed  this  phase  of  the  development 
process,  you  should  have: 

•  A  single  FSI  for  the  entire  system;  or 

•  FSIs  for  the  system  and  each  subsystem,  but  not  for  any 
lower  indenture  items;  or 

•  FSIs  for  the  system  and  each  subsystem  and  for  some  items 
at  lower  indenture  levels. 

A  picture  of  the  third  alternative  for  a  system  having  5 
functions  would  look  like  this: 


EQUIPMENT 

XXX21 


["""I  INDICATES  LEVEL  AT  WHICH  FUNCTION  OCCURS 


1  Remember,  the  use  of  the  additional  FSI  Selection  form  is 
required  only  if  you  wish  to  analyze  individual  items  at  the 
equipment  level,  or  below. 
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One  function  is  unique  to  the  system  as  a  whole^  and  four  are 
distributed  among  three  subsystems.  One  function  of  subsystem  2 
is  unique  to  an  equipment  which  has  been  selected  as  an  FSI.  A 
total  of  five  FSIs  have  been  identified,  and  all  will  be  listed 
in  the  FSI  Index. 


E.  FUNCTIONALLY  SIGNIFICANT  ITEMS  INDEX  (OPNAV  4^90/118) 

The  FSI  Index  simply  lists,  in  hierarchical  order,  all  of 
the  FSIs,  system  by  system.  It  summarizes  all  of  the  work,  done 
to  identify  FSIs.  You  will  prepare  a  Failure  Modes  and  Effects 
Analysis  for  every  item  in  this  index. 


F.  FAILURE  MODES  AND  EFFECTS  ANALYSIS  (OPNAV  4790/119) 

The  Failure  Modes  and  Effects  Analysis  (FMEA)  provides  the 
basic  failure  information  required  for  applying  the  RCM  decision 
logic  for  analyses.  The  FMEA  identifies  the  specific  conditions 
that  are  the  dominant  causes  for  functional  failures  —  the 
conditions  that  a  PM  task  is  intended  to  prevent  or  discover. 2 
The  FMEA  is  intended  to  identify  dominant  failure  modes,  those 
whose  impact,  either  as  individual  or  frequent  events,  requires 
consideration  for  preventive  tasks. 

The  quality  of  the  FMEA  is  the  key  to  the  quality  of  the 
resulting  preventive  maintenance  program.  This  step  in  the 
development  process  requires  a  realistic,  not  an  academic,  evalu¬ 
ation  of  failures.  Active  participation  of  users  at  this  step  in 
the  analysis  will  have  a  major  beneficial  impact.  Be  sure  to 
identify  the  dominant,  real  failure  modes,  not  hypothetical  modes 
that  do  not  or  are  not  likely  to  happen. ^ 


1  This  is  the  level  at  which  TSTP  type-tests  will  usually  be 
performed. 

^  This  objective  is  not  the  same  as  that  for  the  FMEA  used  by 
reliability  analysts  in  the  design  process.  However,  if  an 
FMEA  complying  with  MIL-STD-1629  (SHIPS)  has  been  previously 
prepared,  it  will  be  a  valuable  source  of  information. 

3  Some  functional  failures  may  have  no  dominant  failure  modes. 
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Each  FSI  in  the  FSI  Index  requires  an  FMEA.*-  Efficient 
preparation  of  the  FMEA's  requires  a  "bottom  up”  approach  in 
which  the  lowest  level  FSIs  are  analyzed  first,  followed  by  the 
associated  subsystem  and  system  level  FSIs.  Identify  failure 
modes  at  the  lowest  FSI  level  at  which  they  can  be  perceived.  Do 
not  repeat  these  at  higher  indenture  levels. 


G.  HIDDEN  FUNCTIONS  ANALYSIS  (OPNAV  4790/127) 

A  hidden  function  is  a  function  not  apparent  during  normal 
operations.  It  may  be  a  back-up  mode  that  is  manually  or  auto¬ 
matically  selected  when  the  primary  source  of  the  function  falls, 
or  it  may  be  a  warning  or  protective  function  that  is  activated 
by  a  temperature,  pressure,  or  vibration  sensor. 

The  Hidden  Functions  Analysis  identifies  these  functions  and 
determines  whether  they  are  covered  by  existing  PM  tasks. 


H.  DECISION  LOGIC  TREE  ANALYSIS  (OPNAV  4790/120) 

The  process  for  identifying  applicable  and  effective  tasks 
uses  a  decision  logic  tree.  A  decision  logic  tree  uses  a  group 
of  sequential  yes/no  questions  to  classify  or  characterize  "some¬ 
thing.”  This  something  may  be  a  thing,  a  fact,  or  an  event.  In 
this  application,  it  is  an  event,  a  functional  failure.  The 
answers  to  these  questions  will  ultimately  tell  us  about  this 
failure's  criticality  (which  may  be  different  for  each  failure 
mode)  and  whether  there  is  an  applicable  and  effective  mainte¬ 
nance  task  that  will  control  it.  The  decision  logic  tree  for 
doing  what  we  have  in  mind  is  shown  in  Figure  V-2.  Note  that  the 
first  three  questions  determine  classification  while  the  remain¬ 
ing  questions  deal  with  the  search  for  applicable  and  effective 
tasks  or  with  an  alternative  action,  changing  the  design  of  the 
hardware. 

Applying  this  logic  will  identify  what,  if  any,  preventive 
maintenance  task(s)  should  be  performed.  Unavailability  of 
safety-critical  on-line  functions  or  expectation  of  safety- 
critical  failures  requires  either  a  task  or  specific  acceptance 
of  the  alternative  risks.  If  availability  of  non-safety-critical 
on-line  functions  or  non-safety-critical  failures  are  affected, 


1  If  all  functional  failures  are,  in  fact,  completely  con¬ 
sidered  at  lower  Indenture  levels,  the  FMEA  should  simply  state 
that  fact,  and  the  remainder  of  the  form  should  be  left  'jlank. 
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economic  trade-offs  determine  task  desirability*  (On-line  fail¬ 
ures  directly  affecting  operations  are  treated  separately  from 
those  of  support  functions  because  of  their  higher  level  of 
Impact . ) 

Off-line  functions  are  considered  separately.  They  are  of 
two  kinds  —  hidden  functions  that  protect  the  ship  from  multiple 
failures1-  and  military  mission  functions  not  used  frequently 
enough  to  provide  confidence  that  they  will  be  available  when 
required.  Either  preventive  or  failure-finding  tasks  are 
required,  when  necessary,  to  ensure  acceptable  availabilities  of 
these  functions. 

Since  the  quality  of  the  results  of  applying  the  decision 
logic  depends  considerably  on  the  understanding  of  each  of  the 
questions  in  the  tree,  let's  review  each  question  in  some  detail. 

1.  Is  the  occurence  of  a  failure  evident  to  the  operating 
crew  while  It  Is  performing  its  normal  duties? 

This  question  divides  functional  failures  into  two 
groups: 

•  Those  that  reveal  themselves  to  the  crew  during  their 
normal  day-to-day  activities  (on-line  functions) .  (Be 
sure  you  know  exactly  how  this  can  occur.) 
e  Those  that  are  discovered  when  operation  of  infre- 
quently-used  equipment  la  attempted  or  when  protective 
or  back-up  systems  fall  to  operate  when  needed  (off¬ 
line  functions). 

2.  Does  the  failure  cause  a  loss  of  function  or  secondary 
damage  that  has  a  direct  and  adverse  effect  on  operating 
safety? 

This  question  divides  on-line  functional  failures  into 
two  groups: 

e  Those  that  directly  impact  operating  safety.  Safety 
relates  to  threats  to  life  and  limb  of  the  crew  or 
others,  not  to  equipment  damage  that  does  not  threaten 
people.  It  Involves  direct,  major  threats,  not 
improbable  combinations  of  events  that  have  minor 
Impact  or  are  unlikely. 

If  you  are  developing  an  Initial  program  for  a  new  ship,  you  will 
have  to  determine  the  impact  of  failures  by  reviewing  drawings, 
specifications,  and  experience  with  similar  designs.  If  there  Is 
already  considerable  ln-servlce  experience,  be  sure  that  you 
examine  this  experience  to  see  whether  safety  has.  In  fact,  been 
affected  by  this  failure. 


1 
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Either  loss  of  redundancy  or  unavailability  of  a  protection 
system,  for  example. 


•  Those  that  do  not  impact  operating  safety  as  described 
above.  These  failures  have  economic  impact  in  the 
sense  that  failure  deprives  the  user  of  a  function 
that  has  value  to  him. 

3.  Does  the  failure  have  a  direct  and  adverse  effect  on 
operational  capability? 

This  question  divides  the  non-safety-related  on-line 
failures  into  two  groups: 

•  Those  that  directly  impact  operations.  These  failures 
affect  the  ability  of  the  ship  to  perform  its  function 
as  a  ship,  including  any  military  functions  in 
regular,  frequent  use;  and 

•  Those  that  impact  support  functions  in  regular,  fre¬ 
quent  use. 

4, 5, 6, 7.  Is  there  an  applicable  and  effective  preventive  mainte¬ 
nance  task  or  combination  of  task(s)  that  will  prevent 
functional  failures? 

Do  not  limit  your  answer  by  consideration  of  the  mainte¬ 
nance  level  at  which  these  tasks  will  be  done.  This 
question  applies  to  all  functional  failures  irrespective 
of  their  repair  level  and  separates  them  into  two 
groups : 

•  Those  for  which  an  effective  and  applicable  preventive 
maintenance  task  (or  tasks)  can  be  specified.  Appli¬ 
cable  means  the  task  has  the  desired  effect  (really 
prevents  or  reduces  the  impact  of  functional 
failures).  Effective,  for  safety-related  failures, 
means  that  risk  is  reduced  to  an  acceptable  level, 
and,  for  other  than  critical  safety  failures,  that 
the  task  is  cost-effective.  Each  task,  will  be  either 
a  time-directed  task,  (life  limit  (LL)  or  rework/ over¬ 
haul  (RW)  task),  or  a  condition-directed  task  (CD), 
for  example,  a  periodic  check  against  some  measurable 
standard. 

—  Time-directed  tasks  (RW  or  LL)  can  be  applicable 
only  if  the  probability  of  failure*-  increases 
with  time.  This  time  can  be  measured  many  differ¬ 
ent  ways — some  easy,  some  very  difficult.  Whatever 
the  basis  for  time  measurement,  its  relationship  to 
failure  probability  must  be  as  described  above  if 
the  task  Is  to  be  effective  and  time  measure 
selected  is  to  be  practicable. 


*•  More  precisely,  the  hazard  rate  or  conditional  probability 
of  failure. 
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—  Condition-directed  tasks  (CD)  can  be  effective  only 
if  they  efficiently  convert  functional  failures  to 
potential  failures.  Their  effectiveness  usually 
depends  on  their  ability  to  eliminate  a  high  per¬ 
centage  of  functional  failures  at  a  low  cost  per 
task. 

•  Those  for  which  there  is  no  applicable  and  effective 
task. 

8.  Can  redesign  change  criticality  class? 

This  question  addresses  the  problem  of  safety-related 
functional  failures  for  which  there  is  no  applicable  and 
effective  preventive  maintenance  task.  Avoid  the  tempta¬ 
tion  to  specify  an  ineffective  task  or  collection  of 
tasks.  Address  the  practicability  of  changing  the  design 
in  order  to  avoid  these  failures.  If  redesign  is  imprac¬ 
ticable,  then  specifically  identify  the  associated  risk. 
(See  Section  J.) 

9.  Is  a  scheduled  functional  failure-finding  task  justi¬ 
fied? 

This  question  determines  the  need  for  a  failure-finding 
task  (FF).  These  tasks  are  not  preventive,  but  they  are 
Intended  to  discover  failures  that  are  otherwise  hidden 
from  the  user.  Occasionally,  a  hidden  function  provided 
by  the  design  is  either  so  reliable  or  the  function  is  so 
trivial  that  no  task  can  be  justified. 


I.  SERVICING  AND  LUBRICATION  ANALYSIS  (OPNAV  4790/121) 

Servicing  and  lubrication  are,  of  course,  preventive  mainte¬ 
nance  tasks.  (Servicing  consists  of  the  routine  replenishment  of 
bulk  consumables  other  than  lubricants.  These  include  hydraulic 
fluid,  coolants,  etc.)  These  tasks  could  be  established  by  using 
the  RCM  logic  and,  in  fact,  you  may  have  established  some.  Since 
it  i 8  important  that  tasks  of  this  kind  not  be  overlooked  (as 
they  may  be  because  they  are  often  taken  for  granted),  this 
analysis  takes  an  overall  look  at  servicing  and  lubrication 
requirements.  It  is  based  on  review  of  existing  requirements, 
either  in  PMS  for  existing  ships  or  manufacturers'  recommenda¬ 
tions  for  new  ships  and  equipment.  Focus  on  minimum  requirements. 
Keep  in  mind  that  manufacturers'  recommendations  tend  to  be 
excessive.  Don't  overkill  because  you  doubt  that  the  user  will 
do  what  you  require.  Remember  that  the  job  will  more  likely  be 
done  if  you  specify  common  materials  and  sensible  periodicities. 
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J.  SAFETY -RELATED  DESIGN  CHANGE  RECOMMENDATION 
(OPNAV  4790/122) 

The  Decision  Logic  Tree  recognizes  that  there  will  be 
Instances  when  a  functional  failure  has  a  direct,  adverse  impact 
on  safety  and  there  is  no  highly  effective  preventive  task.  The 
Safety-Related  Design  Change  form  provides  a  means  for  document¬ 
ing  your  recommendations,  if  this  situation  occurs.  Note  that 
you  should  restrict  these  recommendations  to  safety-related 
failures.  Do  not  use  this  form  to  address  a  non-safety-related 
design  improvement. 
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APPENDIX  A 
GLOSSARY 


ACTIVE  FUNCTION  A  function  requiring  some  specific 

action  of  a  hardware  element* 

APPLICABLE  TASK  A  task  that  reduces  the  impact  or 

occurrence  of  failure. 

COMMON  CAUSE  FAILURES  Failures  resulting  from  the  same  casual 

event. 

CO-FUNCTION  A  function  unrelated  to  another 

function  that  is  provided  "in  parallel" 
by  the  same  unit. 

CONDITION-DIRECTED  TASK  A  task  that  compares  condition  or  per¬ 
formance  with  a  specific  standard. 

COST-EFFECTIVE  An  efficient  user  of  resources. 

DECISION  TREE  A  structured  sequential  decision 

process,  usually  consisting  of  a  series 
of  binary  questions. 

DOMINANT  FAILURE  MODE  A  failure  mode  that  is  important  either 

as  an  event  or  because  of  Its  frequent 
occurrence. 


EFFECTIVE  TASK  A  task  that  is  worth  doing. 


FAILURE  An  unsatisfactory  condition. 

FAILURE  EFFECT  The  end  effect  of  a  specific  failure. 

FAILURE-FINDING  TASK  A  task  that  discovers  a  hidden  failure. 

FAILURE  MODE  The  specific  condition  causing  a 

functional  failure  (often  best 
described  by  the  condition  after 
failure) . 

FUNCTION  A  capability  of  a  hardware  element  that 

0  is  a  specific  requirement  of  its 

design. 

FUNCTIONAL  FAILURE  Loss  of  a  function  or  degradation  below 

the  operationally  required  performance 
level. 
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HIDDEN  FUNCTION  A  function  not  apparent  to  the  user 

during  normal  operation. 

INDEPENDENT  FAILURE  A  failure  not  related  to  any  other 

failure. 

INHERENT  RELIABILITY  The  reliability  that  is  characteristic 

of  the  design. 

0FF*LINE  FUNCTION  A  function  not  continuously  or  con¬ 

tinually  provided  that  is  activated 
by  some  action  or  event. 

ON-LINE  FUNCTION  A  function  continuously  or  continually 

provided  during  normal  operation. 

PASSIVE  FUNCTION  A  function  provided  without  specific 

action  of  a  hardware  element  (e.g., 
containment ,  insulation,  etc.). 

POTENTIAL  FAILURE  A  failure  defined  by  test  or  inspection 

criteria  rather  than  by  operational 
performance. 

PREVENTIVE  MAINTENANCE  Scheduled,  periodic  action  intended 

either  to  prevent  or  discover  failures. 

PRIMARY  FUNCTION  The  most  important  function. 

REDUNDANCY  System  capacity  in  excess  of  require¬ 

ments  that  avoids  loss  of  function  as 
the  result  of  item  failure. 

RELIABILITY-CENTERED  Focused  on  maintaining  inherent  relia¬ 

bility. 

SAFETY  Protection  from  threats  to  life  or 

limb. 

SECONDARY  FUNCTION  Not  the  primary  function. 

TIME-DIRECTED  TASK  A  task  performed  solely  on  the  basis  of 

time  (or  a  cumulative  number  of 
events)  since  some  previous  action. 
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APPENDIX  B 

PLANNED  MAINTENANCE  SYSTEM 
DEVELOPMENT  FORMS 


The  forms  illustrated  in  this  appendix  will  guide  the 
analyst  in  performing  an  RCM-based  systems  study  as  described  in 
Section  IV. 
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MASTEB  SYSTEMS  AND  SUBSYSTEMS  INOE* 
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Figure  B-l 
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1  SWAB  NUMBER 
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_ 1 - - 
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9  DESCRIPTION  (A<kj  Additional  sheet,  if  necessary* 
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13  SERIAL  NUMBER 


FUNCTIONAL  FAILURE  ANALYS 
OPMAV  «790«'  16  (ED  2  62> 
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Figure  B-2 
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Figure  B-3 
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Figure  B-4 


FAILURE  MOOES  AND  EFFECTS  ANALYSIS 
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Figure  B-10 
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